Conservative garbage collectors that can be used with general memory allocators

ABSTRACT

A memory manager comprises a memory allocator and a garbage collector. The memory allocator is configured to allocate memory for objects within a heap on behalf of a process, generate a heap map comprising a plurality of heap map entries, wherein each heap map entry of the plurality of heap map entries includes an address of an object allocated within the heap, and provide the heap map to the garbage collector. The garbage collector is configured to generate a mark list identifying one or more objects within the heap using the heap map, wherein the addresses of the one or more objects correspond to data values specified within an address space of the process, and to free a given object previously allocated in the heap if the mark list indicates that an address of the given object does not correspond to a data value specified within the address space.

CROSS REFERENCES TO RELATED APPLICATIONS

This patent application claims priority from U.S. Provisional PatentApplication 60/232,205, M. Spertus, et al., Conservative garbagecollection for general memory allocators, filed 13 Sep. 2000.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention pertains to memory management in computer systemsgenerally and pertains more particularly to management of memory thatbelongs to a process's heap.

2. Description of Related Art: FIG. 1

In a computer system, a given execution of the code for a program isperformed by a process that runs on the computer system. Each processhas its own address space, i.e., a range of addresses that areaccessible only to the process, and the program's code and the data forthe given execution are all contained in the process's address space. Aprocess's address space exists only for the life of the process.

FIG. 1 shows a process address space 102 as it appears during executionof an application program 105 that is written in a language such as C orC++ which permits the programmer to explicitly allocate and free memoryfor the program in process address space 102. Process address space 122is subdivided into a number of different areas. Program code 103contains the code for the program. The code includes the code forapplication program 105 and other code that is invoked by applicationprogram 105; here, the only additional code shown is for allocator 111,which is library code that allocates and frees memory. Next comes staticstorage 117, which contains static data used by application program 105and the library code that is executed by application program 105. Thencomes stack 121, which contains storage for data belonging to eachprocedure currently being executed by program 105. Then comes unusedaddress space 123. Finally, there is heap 125, which contains storagewhich is explicitly allocated and freed by statements in program 105that invoke functions in allocator 111. The size of both stack 121 andheap 125 may increase and decrease during execution of applicationprogram 105; if address space 123 is completely consumed, the processcannot continue to execute application program 105 and the process issaid to crash.

Continuing in more detail with application program 105 and allocator111, allocator 111 includes a malloc function 113, which allocatesblocks 127 in heap 125, and free function 115, which frees blocks inheap 125. Both of these functions are external, in the sense that theymay be called by other code such as application program 105. This factis indicated in FIG. 1 by the placement of the blocks representing thefunctions along one edge of the block representing the allocator.Allocator 111 maintains data structures including a free list 119 fromwhich all of the free heap blocks 131 can be located; when the allocatorallocates a block 127, it removes the block 127 from free list 119; whenit frees the block, it returns the block 127 to free list 119. If thereare no blocks 127 on free list 119, allocator 111 expands heap 125 intounused address space 123. Allocation is done in response to aninvocation 107 of malloc function 113 in application program 105; theinvocation specifies a size for the block and allocator 111 removes ablock of that size from free list 119 and provides a pointer to theblock to application program 105. A pointer is an item of data whosevalue is a location in the process's address space. Freeing is done inresponse to an invocation 109 of free function 115 in applicationprogram 105; the invocation provides a pointer to the block 127 to befreed and the free function uses the pointer to return the block to freelist 119. Because application program 105 must explicitly allocate andfree blocks in heap 131, application program 105 is said to employexplicit heap management. An example of a widely-used public domainallocator for explicit heap management is Doug Lea's allocator. It isdescribed in the paper, Doug Lea, A memory allocator, which could befound in September, 2001 athttp://gee.cs.oswego.edu/dl/html/malloc.html.

As is apparent from the foregoing, the programmer who writes applicationprogram 105 must take care to avoid two errors in managing heap 125:

-   -   freeing a heap block 127 before application program 105 is        finished using it; and    -   failing to free a heap block 127 after application program 105        is finished using it.

The first error is termed premature freeing, and if the applicationprogram references the block after it has been freed, the block may havecontents that are different from those the program expects. The seconderror is termed a memory leak. If an allocated heap block 127 is notfreed after the program is done using it, the allocated heap block 127becomes garbage, that is, a heap block 127 that is no longer being usedby application program 105, but has not been returned to free list 119,and is therefore not available for reuse by application program 105. Ifthe process executing application program 105 runs long enough, thegarbage that accumulates from a memory leak can consume all of unusedaddress space 123, causing the process to crash. Even before a memoryleak causes a process to crash, the garbage in heap 125 ties upresources in the computer system and degrades the performance of theprocess executing application program 105 and of other processes runningon the computer system.

As application programs have grown in size and complexity, have beenwritten and maintained by many different programmers over a span ofyears, and have been executed by processes that cease running only ifthe computer system they are running on fails, memory allocation errorssuch as memory leaks and premature frees have become an increasinglyimportant problem. The larger and more complex a program is, the greaterthe chance that allocation errors will occur, particularly when aprogrammer working on one part of the program does not understand theconditions under which a heap block allocated by another part of theprogram may-be freed. When the program is used and modified by manydifferent programmers over a period of many years, the risk ofallocation errors increases further. In addition, if a program useslibrary routines provided by third parties such as vendors of operatingsystems, these library routines may contain allocation errors. Finally,the fact that programs which were developed for processes that only ranfor a limited time are now being executed by processes that effectively“run forever” means that memory leaks which were formerly harmless nowresult in sluggish performance and crashes. Problems caused byallocation errors are moreover difficult to diagnose and fix; they aredifficult to diagnose because the state of a process's heap is aconsequence of the entire history of the given execution of the programrepresented by the process; consequently, the manner in which problemscaused by allocation errors manifest themselves will vary from oneprocess to another. They are difficult to fix because the invocation ofthe free function (or lack thereof) which is causing the problem may bein a part of the code which is apparently completely unrelated to thepart which allocated the heap block.

A fundamental solution to the problem of allocation errors is to makeheap management automatic. The programmer is still permitted to allocateblocks 127 in heap 125, but not to free them. The automatic heapmanagement is done by garbage collector code which can be invoked fromother code being executed by the process. A process with automatic heapmanagement is shown at 133 in FIG. 1. Process address space 102 is asbefore, but allocator 111 has been replaced by garbage collector 139.Garbage collector 139 has an external malloc function 141 which isavailable to application program 135. Garbage collector 139 also has afree function 145, but free function 145 is an internal function that isnot available to application program 135, as indicated by the locationof free function 145 within garbage collector 139. Since only the mallocfunction is external, application program 135 contains invocations 137of malloc function 141 but no invocations of free functions 145. Theprocess periodically executes the garbage collector, and when executed,the garbage collector scans heap 125 for heap blocks 127 that are nolonger being used by application program 105 and returns unused heapblocks 127 to free list 119.

When executed, garbage collector 139 determines which heap blocks 127are no longer being used by the process by scanning pointers in theprocess's root data, that is, process data that is not contained in heap125, for example, data in static data area 117, stack 121 and machineregisters, and in allocated heap blocks 129 to see if the pointer beingfollowed points to a heap block 127. If there are no pointers pointingto a given heap block 127, that heap block is not being used by theprocess and can be freed. Garbage collector 139 frees the unused blockas described above: by invoking a free function that returns a pointerto the block to free list 119.

There are many different kinds of garbage collectors; for a generaldiscussion, see Richard Jones and Rafael Lins, Garbage collection,Algorithms for automatic dynamic memory management, John Wiley and Sons,Chichester, UK, 1996. In the following we are concerned withconservative garbage collectors. For purposes of the present discussion,a conservative garbage collector is any garbage collector which does notrequire that pointers have forms which make them distinguishable fromother kinds of data. Conservative garbage collectors can thus be usedwith programs written in languages such as C or C++ that do not givepointers forms that distinguish them from other data. These garbagecollectors are conservative in the sense that they guarantee that theywill not free a heap block that is being used by the process, but do notguarantee that allocated heap blocks 129 contains only blocks that arebeing used by the process.

Conservative garbage collectors include a marker function 143 whichmakes an in use table 120 that contains a list of the locations of allof the allocated heap blocks 129. Marker function 143 then scans theroot data and allocated heap blocks 129 for data which has values thatcould be pointers into heap 105. When it finds such a value, it uses inuse table 120 to determine whether the data points to a heap block; ifit does and the heap block has not yet been marked as in use in table120, marker function 143 marks the block in the table. When the scan iscomplete, the locations for all heap blocks that are in fact in use havebeen marked in in use table 120. The blocks 127 in table 120 that havenot been marked are not being used by the process, and garbage collector139 returns these blocks 127 to free list 119. A commercially-availableexample of a conservative garbage collector is the Great Circle® garbagecollector manufactured by Geodesic Systems, Inc., 414 N. Orleans St.,Suite 410, Chicago, Ill. 60610. Information about the Great Circlegarbage collector can be obtained at the Geodesic Systems, Inc. Website, geodesic.com

The performance of a conservative garbage collector can be enhanced ifthe conservative garbage collector can reduce the number of heap blockspointed to by false pointers. A false pointer is a value that thegarbage collector takes to be a pointer to a heap block 127, but is infact not really a pointer at all. As mentioned above, a conservativegarbage collector treats every data value that can be interpreted as apointer as such; for example, if the pointers in the computer system onwhich the process is running are aligned 32-bit values, the garbagecollector will treat every aligned 32-bit value as a pointer. Theproblem with false pointers is that when an allocated heap block has afalse pointer pointing to it, the false pointer will prevent the garbagecollector from returning the block to the free list even though thereare no (or no more) real pointers pointing to it.

One technique for reducing the number of heap blocks pointed to by falsepointers is blacklisting. When the garbage collector detects a pointerthat points to an area of the heap that does not presently containallocated heap blocks, the pointer is clearly a false pointer. When thegarbage collector detects such a pointer, it blacklists the block byadding it to a list of such blocks; this list is termed the blacklist.When the collector expands the heap into an area that containsblacklisted blocks, it uses the blacklist to determine what blacklistedblocks are in the area. The blacklisted blocks are not placed on thefree list; consequently, only unblacklisted blocks are allocated,thereby reducing the chance that the block being allocated will not beable to be freed because of a false pointer. Like real pointers, falsepointers may disappear as a result of changes in the process's storage;when a mark phase can no longer find any pointers that point to ablacklisted block, the garbage collector returns the blacklisted blockto the free list in the sweep phase.

A problem with prior-art garbage collectors such as garbage collector139 is that garbage collector 139 replaces allocator 111. That factmakes it difficult to retrofit garbage collector 139 to a program whichwas written for an allocator 111. A prior-art technique for retrofittingis employed in the Great Circle garbage collector. When an applicationprogram is to be executed with the Great Circle garbage collector, alibrary of programs that belong to the garbage collector is linked tothe application program when the process that is executing the programbegins running. The library of programs includes functions that manageheap 125, among them a malloc function and a free function that replacethe malloc and free functions 113 and 115 of allocator 111. Thereplacement malloc function is identical to malloc function 141 ofgarbage collector 139; the replacement free function is a function whichdoes nothing and returns; garbage collector 139 then uses its owninternal free function as described above to return blocks 127 that arenot being used by the process to free list 119.

Simply replacing an existing allocator 111 with heap managementfunctions belonging to garbage collector 139 is undesirable whenever thereplacement of the allocator with functions belonging to garbagecollector 139 involves a substantial change or risk of substantialchange in the behavior of the application program that uses theallocator 111. One such situation is with legacy programs that are knownto work well with allocator 111, but where garbage collection would bedesirable to deal with memory leaks caused by third-party libraryroutines that are invoked by the application program. Such ancillaryleaks are termed in the art litter, and the question for thoseresponsible for maintaining the application program is whether theadvantages of using garbage collector 139 for litter collection outweighthe risk of changing a known allocator 111. Another such situation iswhere the application program works better with the allocator itpresently has than it will with the garbage collector's heap managementfunctions. The application program may work better with the allocator itpresently has either because the application program has been optimizedfor use with allocator 111 or a custom allocator has been optimized foruse with the application program. In either case, replacing theallocator with the allocation functions of the garbage collector mayresult in substantial losses of efficiency, either with regard to speedof execution of the allocation functions or with regard to management ofheap 125.

The undesirable effects of replacing an existing allocator 111 with heapmanagement functions belonging to garbage collector 139 are a particularexample of a general problem in the design of conservative garbagecollectors: that the garbage collector not only determines what heapblocks 127 may be freed, but also performs the general heap managementfunctions of an allocator. What is needed, and what is provided by thepresent invention is a conservative garbage collector which can use anyexisting allocator 111 to perform the heap management functions. Such aconservative garbage collector could be used with any applicationprogram, without risk of substantially affecting the applicationprogram's behavior. More fundamentally, the separation of the garbagecollector from the allocator permits modular development of bothallocators and garbage collectors. It is thus an object of the presentinvention to provide a conservative garbage collector which does notinclude heap management functions, but instead uses those provided by anallocator that is separate from the garbage collector.

SUMMARY OF THE INVENTION

The object of the invention is attained by providing a table, termedhereinafter a malloc table, which has a form that is defined by thegarbage collector and that is used to transfer information about theheap between the allocator and the garbage collector. When garbage needsto be collected, the allocator builds the table and invokes the garbagecollector, which uses the table in its mark phase to determine whatblocks are not currently in use. In the sweep phase, the garbagecollector uses the allocator's free function to return the blocks thatare not in use to the free list. The garbage collector also uses thetable in the mark phase to make a blacklist of potential blocks that arepointed to by false pointers and therefore should not be allocated bythe allocator when the allocator next expands the heap. When the garbagecollector returns, the allocator uses the blacklist to decide which ofthe blocks in the expanded portion of the heap may be added to the freelist.

There are three kinds of information in the malloc table:

-   -   a current heap map that is made by the allocator; the current        heap map indicates which of the blocks in the current heap are        collectible, i.e., subject to garbage collection;    -   a mark list that is made by the garbage collector during the        mark phase; the mark list indicates which of the collectible        blocks in the current heap map are pointed to by apparent        pointers in the address space of the process that is executing        the allocator and garbage collector; and    -   a blacklist that is made by the garbage collector during the        mark phase; the blacklist indicates collectible potential blocks        in an area into which the heap may expand which are pointed to        by apparent pointers.

Various aspects of the invention include an allocator and a garbagecollector that are adapted to make and use the malloc table, the malloctable itself, and methods involving the garbage collector, theallocator, and the malloc table. Other objects and advantages will beapparent to those skilled in the arts to which the invention pertainsupon perusal of the following Detailed Description and drawing, wherein:

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is an overview of heap management using a prior-art allocator andheap management using a prior-art garbage collector;

FIG. 2 is a flowchart showing the interaction between a garbagecollector and an allocator where the garbage collection and allocationfunctions have been separated;

FIG. 3 is an overview of an allocator and garbage collector thatinteract as set forth in FIG. 2;

FIG. 4 shows details of the heap structures used in Doug Lea'sallocator; and

FIG. 5 shows details of the malloc and jump tables in a preferredenvironment.

Reference numbers in the drawing have three or more digits: the tworight-hand digits are reference numbers in the drawing indicated by theremaining digits. Thus, an item with the reference number 203 firstappears as item 203 in FIG. 2.

DETAILED DESCRIPTION

The following Detailed Description will begin with a conceptual overviewof a garbage collector which does not use its own heap managementfunctions, but rather those of a separate allocator and will thenprovide a description of a preferred embodiment in which the separateallocator is Doug Lea's allocator.

Conceptual Overview

The reason why prior-art garbage collectors 139 have had their own heapmanagement functions rather than use those provided by an allocator isthat garbage collectors cannot function without detailed knowledge ofthe heap's structure and state; moreover, the efficiency of aconservative garbage collector is improved if blacklisted blocks are notallocated. Examples of the need for detailed knowledge are thefollowing;

-   -   a garbage collector 139 cannot construct and use in use table        120 without detailed knowledge of the sizes and locations of        heap blocks 127;    -   a garbage collector 139 cannot determine when garbage collection        is necessary without detailed knowledge of the current state of        the heap; and    -   a garbage collector 139 cannot keep blacklisted blocks from        being allocated if it does not itself do the allocation.

The problems that must be solved in building a garbage collector that isindependent from an allocator and can use the allocator's heapmanagement functions thus include the following:

-   -   providing the garbage collector with the information about the        heap that it needs to make in use table 120;    -   finding a way of determining when the garbage collector should        run; and    -   finding a way of making sure that the allocator does not        allocate blacklisted blocks.

Ideally, the solutions to these problems should be implementable in anyallocator and should provide the garbage collector and allocator withthe information in a form which is not dependent on the kind ofallocator or the kind of garbage collector.

These problems are solved by modifying the allocator and the garbagecollector as follows:

-   -   the allocator determines from the state of the heap when garbage        collection is necessary;    -   when collection is necessary, the allocator builds a malloc        table; the malloc table is used to pass information about the        heap between the garbage collector and the allocator; as built        by the allocator, it contains the information about the        structure of the heap that the garbage collector needs to mark        blocks 127 that are in use;    -   when the malloc table is finished, the allocator invokes the        garbage collector; in the mark phase, the garbage collector        marks the malloc table to indicate which heap blocks 127 are in        use or are blacklisted; in the sweep phase, the garbage        collector uses the allocator's free function to free heap blocks        that are not in use;    -   when the garbage collector returns, the allocator uses the        blacklist in the malloc table to determine which blocks should        not be allocated because they are pointed to by false pointers.

Because the allocator invokes the garbage collector when garbagecollection is required and provides the garbage collector with theinformation needed for in use table 120, the garbage collector needconcern itself only with marking the heap blocks and freeing unused heapblocks and can use the allocator's free function to do the latter.Because the garbage collector modifies the malloc table to indicateblocks that blacklisted, the allocator can avoid allocating such blocks.Finally, the malloc table can have a standard form that can describe anyheap, and consequently, it can be built and read by any allocator andthe garbage collector can be used with any allocator that can build thestandard malloc table and invoke the garbage collector.

Interaction Between the Allocator and the Garbage Collector: FIG. 2

FIG. 2 is a high-level flowchart of the interaction between an allocatorand a garbage collector that are built according to the principles justset forth. Flowchart 201 is a flowchart of the operation of theallocator's malloc function. As shown at start block 203, the functiontakes a size argument that specifies the size of the block to beallocated and returns a pointer to the new block. First, the functiondetermines whether the state of the heap is such that garbage collectionis needed (decision block 205). Heap states that require garbagecollection will of course depend on the manner in which the heap isimplemented and may also depend on parameters that are set when the heapis initialized. If no garbage collection is needed, malloc takes branch207, removes a heap block of the size specified by size (215) from thefree list, and returns a pointer to the newly-allocated block (217). Ifthe allocation of the block requires an expansion of the heap, mallocuses the black list in the malloc table as last modified by the garbagecollector to determine which blocks in the expanded area should be addedto the free list.

If garbage collection is needed, malloc takes branch 209 and builds themalloc table (211); when the table is finished, it shows the locationsof all blocks currently in heap 125. Then, malloc invokes the garbagecollector (213); included in the invocation is a specifier for thelocation of the malloc table. When the garbage collector returns,garbage collection is finished. After the garbage collector returns,malloc allocates the block and returns the pointer (215,217).

Flowchart 219 is a high-level flowchart of the execution of the garbagecollector. As shown at 221, the garbage collector is invoked with thelocation of the malloc table as an argument; then, the garbage collectorenters the mark phase, in which it scans the process's storage forpointers, uses the malloc table for each pointer to determine whetherthe pointer is a pointer to the memory in a heap block, and marks themalloc table for the heap blocks specified by the pointers (223).

Because the garbage collector of the invention does not include heapmanagement functions, it cannot directly use a blacklist when allocatingblocks. What it does instead is make a blacklist during the mark phaseand adds the blacklist to the end of the malloc table it received fromthe allocator. As shown at block 215 of flowchart 201, when theallocator expands the heap into an area of the process address spacethat includes blacklisted blocks, it does not place the blacklistedblocks on the free list.

Continuing with block 225, once the garbage collector has marked themalloc table and added the blacklisted blocks to it, it begins the sweepphase, in which it reads the marked malloc table up to the point wherethe added blacklist begins and uses the allocator's free function tofree the unused blocks. The garbage collector then returns (227) andmalloc continues as shown in flowchart 201.

Components of the Allocator and Garbage Collector: FIG. 3

FIG. 3 is a high-level block diagram 301 of the components of anallocator and garbage collector that have been configured for theinvention. Allocator 303 contains external malloc and free functions asbefore; malloc 304, however, operates as set forth in FIG. 2 and isconsequently shown invoking garbage collector 302. Allocator 303 alsoincludes two new internal functions: malloc table initializer 306, whichinitializes the malloc table at the beginning of execution of theprocess to which process address space 102 belongs, and malloc tablemaker 305, which malloc 304 uses to fill in the initialized malloc tablebefore the allocator invokes the garbage collector. Garbage collector302 contains an internal marker function 309 which marks the malloctable for in use blocks and the black list and an internal sweepfunction that reads the marked malloc table and uses the allocator'sfree function 115 to free unused heap blocks 127 by returning them tofree list 137.

Heap 117 is shown in more detail than in FIG. 1. Heap 117 has two mainparts: current heap 308, which contains all of the currently-allocatedheap blocks 127, and heap expansion area 316, which allocator 303 mayuse if there are no more heap blocks available in current heap 308. Inaddition to heap blocks 127, heap 117 contains holes 311. These resultwhen an application program 105 or a library routine invoked byapplication program 105 uses a function other than malloc 304 toallocate memory. If the allocated memory is in the area of the processaddress space that is otherwise occupied by heap 117, the result is“holes” in the heap. These holes are not under control of allocator 303,and blocks 127 which are in or overlap the holes should be neitherallocated nor freed by allocator 303. These blocks may, however, containpointers, and thus they must be examined in the garbage collector's markphase. One of these unallocatable blocks is shown at 314(i). Also shownin heap 117 in FIG. 3 are a real pointer 316 pointing to a heap block127(i) in the portion of the heap that is currently being managed byallocator 303, as is indicated by current heap top pointer 313, and afalse pointer 317 pointing to a blacklisted potential heap block 318(i)in an area 316 of the process address space into which the heap may beexpanded. The maximum possible extent of the heap is indicated bypotential heap top pointer 315.

The malloc table is shown in overview at 319. There is a malloc tableentry 333 for each heap block 127 in the current heap, including thosewhich are in or overlap holes 311, and each potential heap block in heapexpansion area 316. Malloc table 319 has area 330 corresponding tocurrent heap 308 and 331 corresponding to heap expansion area 316. Ineach area, the entries are ordered by the location of the block 127 or318 represented by the entry in process address space 102. Each malloctable entry contains two items of information: the location 335 of theheap block represented by the memory and the status 337 of the blockrepresented by the entry. When malloc function 304 makes malloc table319, it sets status in portion 330 of the malloc table to indicatewhether a block 117 is unfreeable, either because it is in or overlaps ahole or because it is currently on the free list.

During the mark phase of garbage collection, marker function 309 setsthe status of entries 333 for blocks 127 in current heap 308 to indicatewhether the block may be freed during the sweep phase; with entries inextension 331 representing potential heap blocks 318, marker function309 sets status 337 to indicate whether the block is on the blacklist.During the sweep phase, sweep function 310 uses free function 115 toreturn the blocks whose malloc table entries indicate that they may befreed to the free list. When malloc 304 extends heap 117, it does notplace blocks whose entries in malloc table extension 331 indicate theyare blacklisted on the free list.

An Implementation Using Doug Lea's Allocator: FIGS. 4 and 5

A preferred embodiment of the allocator and garbage collector of theinvention has been made by modifying Doug Lea's allocator, called in thefollowing Dl-malloc, so that its malloc function produces a malloctable, invokes a version of the Great Circle garbage collector which hasbeen modified to read the malloc table and add a blacklist to it, andwhen the garbage collector returns, use the blacklist to avoid placingblocks pointed to by false pointers on the free list.

Heap Management Structures in DL-Malloc: FIG. 4

FIG. 4 is an overview of the structures which DL-malloc uses to manageits heap. The overview is based on the discussion in the A memoryallocator reference cited earlier. Heap 410 is made up of chunks 411which have sizes ranging from 16 bytes through 2³¹ bytes. The chunks areorganized by size into 128 bins 403(00.127). The bins 408 with chunksizes up to 512 bytes have fixed-size chunks; the bins 409 with chunksizes 576 through 2³¹ bytes have chunks of varying sizes. Each bin has afree list 407 for the free chunks having the size specified for the bin;in the case of size-sorted bins 409, the chunks on the bin's free listare ordered by increasing size. The allocate function goes to the binthat will contain a chunk of the requested size and follows the bin'sfree list until it finds the first chunk that will accommodate therequested size. The allocated chunk has exactly the requested size. Whena chunk in the heap is free and has a neighboring chunk that is free,Dl-malloc coalesces the chunk and the free neighbor and adds thecoalesced chunk to the free list for the bin with the proper size.

A detail of a portion of heap 410 containing three chunks is shown at412. Each chunk 411 has size tags 413 at the beginning and end of thechunk. The size tag gives the size of the chunk, and because there aresize tags at both beginning and end, Dl-malloc can easily manipulateneighboring chunks, as is required to coalesce neighboring chunks. Astatus field 415 follows the top size tag; in the present context, thereare three statuses of interest: FREE, IN_USE, and IS_EXTERNAL. Thelatter status indicates that the chunk is not under control ofDl-malloc, and consequently is part of a hole 311 in the heap. However,as already mentioned, the garbage collector must search such chunks forpointers. As shown at 411(a), a FREE chunk contains a pointer 417 to thenext free chunk in its bin 403 and a pointer 419 to the preceding freechunk in its bin 403. The need to store these pointers puts a lowerlimit on the size of the chunks allocated by Dl-malloc. The pointerspermit Dl-malloc to navigate in both directions along the free list. Inan IN_USE chunk, the free list pointers are overwritten by user data421, as shown with regard to chunk 411(b). Chunk 411(c) is larger thanminimum-sized chunk 411(a); it contains the free list pointers andunused space 423.

Also shown in heap 410 are a number of in use chunks (IUC) 421 that arereachable by real pointers 316 from chunk 411(b). Real pointers 316(band c) are part of user data 421 in chunk 411(b); real pointer 316(b)points to IUC 421(b); the user data in that chunk points to no furtherchunks. Real pointer 316(c) points to IUC 421(c), whose user datacontains pointers 316(d), pointing to IUC 421(d), and 316(e), pointingto IUC 421(e). Any in use chunk 421 may of course be pointed to by anynumber of pointers, and the number of pointers the chunk may contain islimited only by its size.

The Malloc Table and Other Tables Used by the Garbage Collector: FIG. 5

FIG. 5 shows a preferred embodiment 515 of the malloc table. Malloctable 515 has the same general form as malloc table 319: it has a malloctable entry 517 for every chunk within the bounds of heap 410, includingthose contained in or overlapping holes 311. Malloc table entry 517 hastwo fields: the address 519 of the start of the chunk 411 represented bythe entry and the status 521 of the chunk for the current garbagecollection. In a preferred embodiment, there are three statuses ofinterest:

-   -   the chunk is UNCOLLECTIBLE, because the chunk represented by the        entry has either the FREE status (i.e., is on a free list) or        the IS_EXTERNAL status (i.e., is in or overlaps a hole 311);    -   the chunk is COLLECTIBLE and MARKED, i.e., during the mark        phase, the garbage collector found a pointer that points to the        chunk; or    -   the chunk is COLLECTIBLE and UNMARKED; i.e., during the mark        phase, the garbage collector did not find such a pointer.

The malloc table entries in table 515 are ordered by increasing chunkstart address 519. Like malloc table 319, malloc table 515 is dividedinto the malloc table 330 for the current heap and malloc tableextension 331 for heap expansion area 316. Malloc table 515 is alsodivided into a number of pages 523. Each page 523 contains malloc tableentries 517 for a fixed range of start addresses 519; as will beexplained in detail below, the division of malloc table 515 into pagesspeeds searches of the table.

Malloc function 304 builds malloc table 515 when the function determinesthat a garbage collection is necessary. In a preferred embodiment, theconditions under which malloc function 304 builds malloc table 515 andinvokes garbage collector 304 are the following:

-   -   there is not a chunk available in current heap 308 which malloc        can use for the object it is to currently allocate; and    -   the heap minus the estimated live memory remaining after the        last garbage collection exceeds a certain percentage of the        total heap.

If the latter condition is not true, malloc function 304 does not invokethe garbage collector, but merely extends the heap into heap expansionarea 316, using the blacklisting information in the most recent malloctable's malloc table extension 331 to avoid placing chunks in thenewly-extended heap that are pointed to by false pointers 317 on thefree list. If the chunks that are added to the heap via the extensionare still not enough to satisfy the allocation, then malloc function 304adds all chunks in the extension that do not belong to holes 311 to thefree lists in their respective bins.

When malloc table 515 is compared with heap 410, it is clear how themalloc function builds malloc table 515. Beginning at the lowest addressin heap 410, the malloc function reads heap 410 chunk 411 by chunk,making a malloc table entry 517 for each chunk, including those whichwould be located in heap expansion area 316 if the heap were expanded.If additional malloc table entries 517 are needed, the malloc functionadds them to malloc table 515. The entry contains the address of thestart of the chunk. In making malloc table entries 517 for current heap38, the malloc function sets status 521 as follows: if status 415 of thechunk indicates that the chunk's status is FREE or IS_EXTERNAL, status521 is set to UNCOLLECTIBLE; if the chunk's status is IN_USE, status 521is set to COLLECTIBLE and UNMARKED. If the malloc function reaches top313 of the current malloc table before it is finished making entries, itincreases top 313 as it adds entries. When a chunk is IS_EXTERNAL, themalloc function also pushes the start and end addresses of the chunkonto mark stack 507. This ensures that the garbage collector will searchthe holes 311 in heap 410 during the mark phase for pointers to chunksallocated by the malloc function.

When the malloc function has made entries for all of the chunks incurrent heap 308, it continues with the entries for potential chunks inheap expansion area 316. Since there are no real chunks corresponding tothese malloc table entries, the malloc function uses a single size forall of the potential chunks. The malloc table entry for each of thechunks in heap expansion area 316 is set to COLLECTIBLE, ensuring thatmarker 309 will mark the malloc table entry 517 for the chunk if it ispointed to by a false pointer.

When the malloc function is finished building the malloc table, itbuilds jump table 501. The purpose of this table is to speed up thesearch of malloc table 515. Because the entries in malloc table 515 areordered by increasing chunk start address 519, malloc table 515 may besearched by any method, such as a binary search, that can be used withan ordered set of values. With all such methods, however, the time takenfor the search increases with the size of the set of values beingsearched. Jump table 501 determines which page 523 of malloc table 515will have the malloc table entry 517 for the chunk pointed to by apointer, so that only that page has to be searched, instead of theentire malloc table. All pages 523 but the last have the same number ofmalloc table entries 517, and that number is a power of two. Jump table501 has a jump table entry 503 for each page 523; the entry for the pagecontains the index of the first malloc table entry 517 in the page 523.The smaller the page size is, the faster the search, but the larger thejump table.

Mark stack 507 is used during the mark operation to keep track of chunks411 which have been marked because the garbage collector found a pointerthat pointed to the chunk 411, but which themselves have not yet beensearched for pointers to other chunks. Each entry 509 in the mark stackcontains the start address 511 and the end address 513 of a chunk. Asmentioned above, the malloc function pushes a mark stack entry 509 ontomark stack 507 for every chunk 411 which is in or overlaps a hole 311.

Use of the Malloc Table, the Jump Table, and the Mark Stack by theGarbage Collector

In the mark phase, marker 309 looks in the process's root data for dataitems that might be pointers to chunks that are already part of heap 410or are in an area of memory that could become part of heap 410. Eachsuch data item's value must, if taken as a pointer, point to a range ofmemory between the bottom of the heap and potential heap top 315. In thefollowing, such data items will be termed apparent pointers. When marker309 finds such a data item, it proceeds as follows: it first subtractsthe heap base address from the apparent pointer, and then itright-shifts the result the number of bits that correspond to the log(page-523-size). The resulting number j is the index of the jump tableentry 503 for the page 23 that contains the malloc table entry 517 forthe chunk the pointer is pointing to. The jump table entry 503 specifiedby the index contains the index of the malloc-table where the searchwill start, and the next jump table entry 503 contains the index of themalloc table entry 517 where the search will end.

If the apparent pointer points to a chunk 411 that has an entry 517 inmalloc table 515 (i.e., the apparent pointer is either pointing to areal chunk in current heap 308 or is pointing to a potential chunk inheap expansion area 316 and is therefore a false pointer 317), marker309 examines the chunk's malloc table entry 517; if its status isUNCOLLECTIBLE, marker 309 gets the next apparent pointer. If its statusis COLLECTIBLE and MARKED, marker 309 gets the next apparent pointer. Ifits status is COLLECTIBLE and UNMARKED, marker 309 sets its status toMARKED. If the apparent pointer points to a chunk in heap expansion area316, it is a false pointer 317 and marker 309 then gets the nextapparent pointer. If the apparent pointer is not a false pointer, marker309 computes the bounds of the chunk, pushes the bounds onto mark stack507, and then gets the next apparent pointer.

Then, when marker 309 is finished scanning the process's root data, itscans the heap chunks whose bounds have been pushed onto mark stack 507.These heap chunks include the chunks belonging to holes 311 whose boundsthe malloc function pushed to mark stack 507 when it built malloc table515, as well as the heap chunks whose bounds were pushed onto mark stack507 by the marker function. The topmost entry 509 is popped from thestack and the chunk indicated by the entry is scanned; if any apparentpointer is found to a chunk whose malloc table entry 517 is in theCOLLECTIBLE and UNMARKED state, marker 309 changes the chunk's state toCOLLECTIBLE and MARKED. If the chunk is in current heap 308, marker 309places the bounds for the chunk onto mark stack 507. Marker 309continues in this fashion until mark stack 507 is empty. At this point,marker 309 has scanned the root data, the chunks belonging to holes inheap 410, and all chunks that are COLLECTIBLE and has marked all chunksthat are pointed to by apparent pointers. If the marked chunk is incurrent heap 308, the marked chunk is in use; if it is in heap expansionarea 316, it is blacklisted.

For example, if marker 309 has followed real pointer 316(a) to chunk411(b) and chunk 411(b)) is as yet unmarked, marker 309 marks it andpushes its bounds onto mark stack 507.

Later, when marker 309 pops the bounds for chunk 411(b) from mark stack507 and scans chunk 411(b), it finds real pointer 316(b); it followsreal pointer 316(b) to IUC 421(b), marks malloc table entry 517 for thatchunk, and pushes the bounds for RJC 421(b) onto mark stack 507; it doesthe same when it finds real pointer 316(c). When marker 309 later popsthe mark stack entry 509 for IUC 421(b) from mark stack 507, it scans itbut finds no further pointers to heap chunks, so no further entries arepushed onto mark stack 507. On the other hand, when marker 309 pops themark stack entry 509 for IUC 421(c) and scans the chunk, it findspointers 316(d) and (e) pointing respectively to IUC 421(d) and 421(e).For each of these chunks, it marks the chunk's entry in malloc table 515and pushes an entry for the chunk onto mark stack 509. Marker 309 laterprocesses each of these chunks as described for TUC 421(b).

In the garbage collector's sweep phase, sweep function 310 reads theportion 330 of malloc table 515 whose malloc table entries 517 representheap chunks 411 in current heap 308. Each time sweep function 310 findsa malloc table entry 517 in portion 310 whose status is COLLECTIBLE andUNMARKED, it invokes allocator 303's free function to free the heapchunk 411 corresponding to that malloc table entry 517. When sweepfunction 310 has read all of the malloc table entries in portion 330,garbage collector 302 returns as shown in FIG. 2.

Whenever malloc function 304 extends heap 410 into heap expansion area316, it reads the malloc table entries 517 in table portion 331 for thechunks in the portion of heap expansion area 316 into which heap 410 isbeing extended. If the malloc table entry 517 is UNMARKED, mallocfunction 304 places the chunk on a free list for a bin 409; if it isMARKED, malloc function 304 does not place the chunk on a free list,thus effectively blacklisting the chunk. When malloc function 304 nextbuilds malloc table 515, the fact that the blacklisted chunks in theportion of heap expansion area 316 that was last added to current heap308 are not on a free list means that their malloc table entries 517have the COLLECTIBLE status; thus if they remain unmarked after theexecution of marker function 309, they may be put on the free list.

Alternative Embodiments

While malloc table 515 is a single table in a preferred embodiment, itshould be pointed out that the table contains three kinds of logicallyseparate information:

-   -   a current heap map that indicates the locations of all of the        chunks 411 in current heap 308 and which of the chunks are        subject to garbage collection; this map is made by malloc        function 304 and provided to garbage collector 302;    -   a mark list that indicates whether a chunk 411 in current heap        308 is in use; the mark list is made by marker 309 and used by        sweep function 310 to determine which chunks 411 may be freed;        and    -   a blacklist that indicates whether a potential chunk in heap        expansion area 316 has been blacklisted; the blacklist is made        by marker 309 and used by malloc function 304 when it expands        the heap into heap expansion area 316 to determine which of the        chunks in the portion of area 316 into which the heap was        expanded should be placed on the free list.

While there are important advantages to combining the three kinds ofinformation into a single malloc table 515 that is passed between thegarbage collector and the malloc function, other embodiments mayimplement one or more of the logical components as independent datastructures.

Many other alternative embodiments are possible. In some embodiments,garbage collector 302 may do nothing but make the mark map, and in somecases, the blacklist, with malloc function 304 itself reading thelogical mark table and freeing the chunks that are not in use. Moreover,the garbage collector and the allocator may execute in different threadsof a process or in different processes altogether, with informationbeing passed between them by whatever method is required by thearchitecture. In most implementations, the allocator and the garbagecollector will both have access to the address space of the processwhose heap is being managed, but even that is not necessary for thegarbage collector, since all it needs to mark the malloc table is thevalues of pointers used by the process, not the actual pointersthemselves. Finally, though the preferred embodiment employs amark-sweep garbage collector, the techniques disclosed herein can beapplied to any kind of conservative garbage collector, includingmostly-copying garbage collectors as well.

Various optimizations of malloc table 515 are possible as well; thepreferred embodiment uses the jump table to speed up the location ofmalloc table entries; other embodiments may use other techniques tooptimize searches. In the preferred embodiment, the malloc functionbuilds the entire malloc table each time it determines that a garbagecollection is necessary; in other embodiments, the malloc function mayreuse the last malloc table and only recompute entries for blocks whosestatus has changed since the last malloc table was made.

CONCLUSION

The foregoing Detailed Description has disclosed to those skilled in therelevant technologies how to make and use a conservative garbagecollector and an allocator that use a malloc table to transfer theinformation between them that the garbage collector needs to detectunused heap blocks and the allocator needs to manage the heap in a waythat increases the efficiency of the garbage collector. It has alsodisclosed the best mode presently known to the inventors of making andusing their invention. However, as pointed out in the DetailedDescription and as will be immediately apparent to those skilled in therelevant technologies, there are many ways other than the ones disclosedherein in which the principles of the invention can be implemented. Tobegin with, the manner in which a malloc table is built will depend bothon the form of the malloc table and the structures that the allocatoruses to manage the heap. Further, the information that is presentlycarried in a single malloc table may be carried in independent datastructures; finally, the manner in which the heap management functionsare divided between the allocator and the garbage collector may varyfrom implementation to implementation.

For all of the foregoing reasons, the Detailed Description is to beregarded as being in all respects exemplary and not restrictive, and thebreadth of the invention disclosed here in is to be determined not fromthe Detailed Description, but rather from the claims as interpreted withthe full breadth permitted by the patent laws.

1. A system, comprising: a processor; and a memory coupled to theprocessor, wherein the memory stores program instructions executable bythe processor to implement a memory manager comprising: a memoryallocator; and a conservative garbage collector; wherein the memoryallocator is configured to: allocate memory for objects within a heap onbehalf of a process; generate a heap map comprising a plurality of heapmap entries, wherein each heap map entry of the plurality of heap mapentries includes an address of an object allocated within the heap; andprovide the heap map to the conservative garbage collector; and whereinthe conservative garbage collector is configured to: generate a marklist identifying one or more objects within the heap, wherein addressesof the one or more objects correspond to data values specified within anaddress space of the process, wherein said generating comprises usingthe heap map, wherein said generating the mark list includes: tracingmemory comprising a global variable of the process to identify potentialpointers to heap objects, wherein a data value specified in the globalvariable is identified as a potential pointer to a heap object if thedata value represents a numeric quantity greater than or equal to astarting address of the heap and less than an ending address of theheap; and in response to identifying a potential pointer to a heapobject, creating an entry in the mark list for the heap object pointedto by the potential pointer; and, free a given object previouslyallocated in the heap if the mark list indicates that an address of thegiven object does not correspond to a data value specified within theaddress space.
 2. The system as recited in claim 1, wherein, ingenerating the mark list, the conservative garbage collector is furtherconfigured to: set a mark indicator associated with a particular heapmap entry of the plurality of heap map entries to a particular value ifthe conservative garbage collector identifies a potential pointer withinthe address space of the process to the particular object whose addressis included in the particular heap map entry.
 3. The system as recitedin claim 1, wherein, prior to providing the heap map to the conservativegarbage collector, the memory allocator is configured to set acollectibility indicator associated with a particular heap map entry ofthe plurality of heap map entries to a particular value if a triggeringcondition is met, wherein the particular value indicates that the objectis not collectible by the conservative garbage collector.
 4. The systemas recited in claim 3, wherein the triggering condition comprises adetermination that the object whose address is included within theparticular heap map entry overlaps with a hole in the heap, wherein thehole comprises a region of memory not managed by the memory allocator.5. The system as recited in claim 3, wherein the triggering conditioncomprises a determination that memory corresponding to the object whoseaddress is included within the particular heap map entry has been freed.6. The system as recited in claim 1, wherein the heap map comprises aplurality of memory pages, wherein the memory allocator is furtherconfigured to generate a jump table comprising a plurality of jump tableentries, wherein each jump table entry includes an index to a respectivepage of the heap map; and provide the jump table to the conservativegarbage collector; and wherein in generating the mark list, theconservative garbage collector is further configured to use the jumptable to look up objects in the heap map.
 7. The system as recited inclaim 1, wherein the conservative garbage collector is furtherconfigured to: generate a blacklist specifying one or more addresses ofmemory blocks within an unallocated memory region, wherein saidaddresses are specified as data values within an address space of theprocess; and provide the blacklist to the memory allocator.
 8. Thesystem as recited in claim 7, wherein the memory allocator is furtherconfigured to: receive the blacklist from the conservative garbagecollector; and in response to a detection of a triggering conditionindicating that the heap is to be expanded, expand the heap, whereinsaid expanding comprises selecting one or more additional memory blockswhose addresses are not specified in the blacklist, and including theone or more additional memory blocks in a free list of memory blocks ofthe heap.
 9. The system as recited in claim 7, wherein the conservativegarbage collector is further configured to append the blacklist to theheap map.
 10. The system as recited in claim 1, wherein the memoryallocator is implemented independently of the conservative garbagecollector.
 11. The system as recited in claim 10, wherein theconservative garbage collector is configured to invoke a functionprovided by the memory allocator to free the given object.
 12. Thesystem as recited in claim 1, wherein the memory allocator is furtherconfigured to: in response to a detection of a triggering condition,invoke an execution of the conservative garbage collector.
 13. Acomputer-implemented method, comprising: allocating, at a memoryallocator, memory for objects within a heap on behalf of a process;generating, at the memory allocator, a heap map comprising a pluralityof heap map entries, wherein each heap map entry of the plurality ofheap map entries includes an address of an object allocated within theheap; and providing the heap map to a conservative garbage collector;generating, at the conservative garbage collector, a mark listidentifying one or more objects within the heap, wherein addresses ofthe one or more objects correspond to data values specified within anaddress space of the process, wherein said generating comprises usingthe heap map, and wherein said generating includes: tracing memorycomprising a global variable of the process to identify potentialpointers to heap objects, wherein a data value specified in the globalvariable is identified as a potential pointer to a heap object if thedata value represents a numeric quantity greater than or equal to astarting address of the heap and less than an ending address of theheap; and in response to identifying a potential pointer to a heapobject, creating an entry in the mark list for the heap object pointedto by the potential pointer; and, freeing, at the conservative garbagecollector, a given object previously allocated in the heap if the marklist indicates that an address of the given object does not correspondto a data value specified within the address space.
 14. Thecomputer-implemented method as recited in claim 13, wherein saidgenerating the mark list at the conservative garbage collectorcomprises: setting a mark indicator associated with a particular heapmap entry of the plurality of heap map entries if the conservativegarbage collector identifies a potential pointer within the addressspace of the process to the particular object whose address is includedin the particular heap map entry.
 15. The computer-implemented method asrecited in claim 13, further comprising: prior to providing the heap mapto the conservative garbage collector, determining, at the memoryallocator, whether a triggering condition has been met; and in responseto determining that the triggering condition has been met, the memoryallocator setting a collectibility indicator associated with aparticular heap map entry of the plurality of heap map entries to avalue indicating that the particular object whose address is included inthe particular heap map entry is not collectible by the conservativegarbage collector.
 16. The computer-implemented method as recited inclaim 15, wherein the triggering condition comprises a determinationthat the object whose address is included within the particular heap mapentry overlaps with a hole in the heap, wherein the hole comprises aregion of memory not managed by the memory allocator.
 17. Thecomputer-implemented method as recited in claim 15, wherein thetriggering condition comprises a determination that the object whoseaddress is included within the particular heap map entry is an objectwhose memory has been freed.
 18. The computer-implemented method asrecited in claim 13, wherein the heap map comprises a plurality ofmemory pages, further comprising: generating a jump table comprising aplurality of jump table entries, wherein each jump table entry includesan index to a respective page of the heap map; and providing the jumptable to the conservative garbage collector; wherein said generating themark list at the conservative garbage collector comprises using the jumptable to look up objects in the heap map.
 19. The computer-implementedmethod as recited in claim 13, further comprising: generating, at theconservative garbage collector, a blacklist specifying one or moreaddresses of memory blocks within an unallocated memory region, whereinsaid addresses are specified as data values within an address space ofthe process; and provide the blacklist to the memory allocator.
 20. Thecomputer-implemented method as recited in claim 19, further comprising:receiving the blacklist at the memory allocator; and, in response to adetection of a triggering condition indicating that the heap is to beexpanded, the memory allocator expanding the heap, wherein saidexpanding comprises selecting one or more additional memory blocks whoseaddresses are not specified in the blacklist, and including the one ormore additional memory blocks in a free list of memory blocks of theheap.
 21. The computer-implemented method as recited in claim 19,wherein said providing the blacklist to the memory allocator comprisesappending the blacklist to the heap map.
 22. The computer-implementedmethod as recited in claim 13, wherein said providing the heap map tothe conservative garbage collector comprises: invoking an execution ofthe conservative garbage collector from the memory allocator, whereinsaid invoking comprises passing the heap map as an input parameter tothe conservative garbage collector.
 23. A computer readable mediumcomprising program instructions, wherein the instructions arecomputer-executable to implement a memory manager comprising a memoryallocator and a conservative garbage collector, wherein the memoryallocator is configured to: allocate memory for objects within a heap onbehalf of a process; generate a heap map comprising a plurality of heapmap entries, wherein each heap map entry of the plurality of heap mapentries includes an address of an object allocated within the heap; andprovide the heap map to the conservative garbage collector; and whereinthe conservative garbage collector is configured to: generate a marklist identifying one or more objects within the heap, wherein addressesof the one or more objects correspond to data values specified within anaddress space of the process, wherein said generating comprises usingthe heap map, and wherein said generating includes: tracing memorycomprising a global variable of the process to identify potentialpointers to heap objects, wherein a data value specified in the globalvariable is identified as a potential pointer to a heap object if thedata value represents a numeric quantity greater than or equal to astarting address of the heap and less than an ending address of theheap; and in response to identifying a potential pointer to a heapobject, creating an entry in the mark list for the heap object pointedto by the potential pointer; and, free a given object previouslyallocated in the heap if the mark list indicates that an address of thegiven object does not correspond to a data value specified within theaddress space.
 24. The computer readable medium as recited in claim 23,wherein, in generating the mark list, the conservative garbage collectoris further configured to: set a mark indicator associated with aparticular heap map entry of the plurality of heap map entries to aparticular value if the conservative garbage collector identifies apotential pointer within the address space of the process to theparticular object whose address is included in the particular heap mapentry.
 25. The computer readable medium as recited in claim 23, wherein,prior to providing the heap map to the conservative garbage collector,the memory allocator is configured to set a collectibility indicatorassociated with a particular heap map entry of the plurality of heap mapentries to a particular value if a triggering condition is met, whereinthe particular value indicates that the object is not collectible by theconservative garbage collector.
 26. The computer readable medium asrecited in claim 25, wherein the triggering condition comprises adetermination that the object whose address is included within theparticular heap map entry overlaps with a hole in the heap, wherein thehole comprises a region of memory not managed by the memory allocator.27. The computer readable medium as recited in claim 25, wherein thetriggering condition comprises a determination that memory correspondingto the object whose address is included within the particular heap mapentry has been freed.
 28. The computer readable medium as recited inclaim 23, wherein the conservative garbage collector is furtherconfigured to: generate a blacklist specifying one or more addresses ofmemory blocks within an unallocated memory region, wherein saidaddresses are specified as data values within an address space of theprocess; and provide the blacklist to the memory allocator.
 29. Thecomputer readable medium as recited in claim 28, wherein the memoryallocator is further configured to: receive the blacklist from theconservative garbage collector; and in response to a detection of atriggering condition indicating that the heap is to be expanded, expandthe heap, wherein said expanding comprises selecting one or moreadditional memory blocks whose addresses are not specified in theblacklist, and including the one or more additional memory blocks in afree list of memory blocks of the heap.
 30. The computer readable mediumas recited in claim 28, wherein the conservative garbage collector isfurther configured to append the blacklist to the heap map.
 31. Thecomputer readable medium as recited in claim 23, wherein the memoryallocator is implemented independently of the conservative garbagecollector.
 32. The computer readable medium as recited in claim 23,wherein the memory allocator is further configured to: in response to adetection of a triggering condition, invoke an execution of theconservative garbage collector.
 33. The computer readable medium asrecited in claim 23, wherein the heap map comprises a plurality ofmemory pages, wherein the memory allocator is further configured togenerate a jump table comprising a plurality of jump table entries,wherein each jump table entry includes an index to a respective page ofthe heap map; and provide the jump table to the conservative garbagecollector; and wherein in generating the mark list, the conservativegarbage collector is further configured to use the jump table to look upobjects in the heap map.